Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / eft100.arc / EFT.PRT < prev next >

Wrap

Text File | 1991-07-03 | 157KB | 2,966 lines

EFT enhanced file transfer 07-03-91 11:23am Page i Table of Contents 1. Introduction.................................................. 2 2. Features...................................................... 4 3. Requirements.................................................. 8 4. Installation.................................................. 9 1. Command line parameters.................................. 9 2. Downloads............................................... 10 3. Uploads................................................. 10 4. FD_UPD,FILEDOOR.PRM..................................... 11 5. EFT.CFG, the configfile...................................... 12 1. LogFile................................................. 12 2. Colour.................................................. 12 3. Color................................................... 12 4. FreeFile................................................ 13 5. Protocol................................................ 13 6. PrivateUploads.......................................... 13 7. DefaultExtension........................................ 14 8. UploadLog............................................... 14 9. DownloadLog............................................. 14 10. NoAreaNames............................................ 14 11. FilesCount............................................. 14 12. NoArchiveCredit........................................ 15 13. ArchiveExtension....................................... 15 14. CheckDupes............................................. 16 15. NoSimilars............................................. 17 16. AutoSearch............................................. 17 17. DownloadHours.......................................... 18 18. TouchUploads........................................... 18 19. NoStatLine............................................. 18 20. TempDrive.............................................. 19 21. FileDoorDir............................................ 19 22. AskAnother............................................. 19 23. MinSpace............................................... 19 24. Unwanted............................................... 19 25. DescLen................................................ 19 26. MinBaud................................................ 19 27. FreeRatio.............................................. 20 28. CorrectKbytes.......................................... 20 29. TimeOut................................................ 20 30. BreakDir............................................... 20 31. SwapDir................................................ 20 32. Desc................................................... 21 33. ShutUp................................................. 21 34. BadFiles............................................... 21 35. YesNo.................................................. 21 36. UploadCredit........................................... 21 37. KeepBroken............................................. 21 38. Unlinkbroken........................................... 22 39. MinGIF................................................. 22 40. MinPCX................................................. 22 41. LogStyle............................................... 22 42. LogLevel............................................... 22 43. InfoFile, ............................................. 22 44. InfoFileHeader ........................................ 23 EFT enhanced file transfer 07-03-91 11:23am Page ii 45. UploadName............................................. 23 46. PICResolution.......................................... 23 47. EmbeddedCodes.......................................... 23 48. UseEGA................................................. 23 49. AutoTransfer........................................... 23 50. MaxLimit............................................... 23 51. TagFiles............................................... 24 52. Protocol............................................... 25 1. General............................................ 25 2. The protocol line.................................. 26 3. The interface line................................. 27 1. DSZ........................................... 27 2. Opus.......................................... 27 3. ErrorLevel.................................... 27 4. Other......................................... 28 5. CDS........................................... 28 6. Macros on the commandline..................... 30 4. The behavior line.................................. 31 1. ArcTest....................................... 32 2. ErrorLevel=................................... 32 3. GoodFile=..................................... 32 4. Opus11X....................................... 33 5. SendInfos..................................... 33 6. GetInfos...................................... 33 7. NoLeading..................................... 34 8. Resume........................................ 34 9. Cls........................................... 34 10. Window=...................................... 34 11. ArcWindow=................................... 35 12. SlowBIOS..................................... 35 13. LeaveUploads................................. 35 14. NofilesOK.................................... 35 6. Supported files.............................................. 37 1. System files............................................ 37 1. FILES.CTL.......................................... 37 2. BADFILES.CTL....................................... 37 3. LIMITS.CTL......................................... 38 4. FLSEARCH.CTL....................................... 39 5. FILES.EFT ......................................... 39 2. Display files........................................... 40 1. HLP_UP.A??,HLP_DOWN.A??............................ 41 2. HLP_CMD.A??........................................ 41 3. EFT_UP.A??,EFT_DOWN.A??............................ 41 4. UPHINTS.A??,DWNHINTS.A??........................... 41 5. EFT_CMD.A??........................................ 41 6. BADFILES.A??....................................... 42 7. DNLDHRS.A??........................................ 42 8. RATIO.A?? ......................................... 42 9. RATIOK.A?? ........................................ 42 10. TOOSLOW.A??....................................... 42 11. STARTCHT.A??,ENDCHT.A??........................... 42 12. TODAYK.A??........................................ 42 13. PWDERROR.A??...................................... 42 14. TAGGER.A??........................................ 43 7. Samples,Notes................................................ 44 EFT enhanced file transfer 07-03-91 11:23am Page iii 1. Commandline Samples..................................... 44 2. General Notes........................................... 44 1. HotKeys ........................................... 44 2. Networks .......................................... 45 3. RAM usage.......................................... 45 4. Fast Modems........................................ 45 5. Hidden files....................................... 46 6. Swapping........................................... 46 7. Private files...................................... 47 8. Limit Checkers..................................... 48 3. Trouble-Shooting and Questions.......................... 48 4. Maxima.................................................. 51 ┌────────┐ │ ┌─────┐ │ │ ├─┼──┬─┐ │ │ │ enhanced file transfer door │ │ │ v 1.0 └────────┘ Documentation and Software is written by and Copyright (C) Michael Raus, Raus EDV-Systeme, 1991 All Rights Reserved Released 07-03-91 11:23am EFT enhanced file transfer 07-03-91 11:23am Page 2 1. Introduction --------------- Welcome to EFT v1.0. EFT allows external file-transfer programs to be used for uploading and downloading with Remote Access Bulletin Board Systems of all versions and SuperBBS V 1.x. I don't think its too much to call EFT the next step in BBS transfer managers when it comes to features and flexibility regarding uploading and downloading - But check for yourself in the feature list below! PLEASE NOTE: This is a rather large document - Instead of providing skinny documentation, I've tried to cover as much as possible here, in an attempt to avoid false bug-reports, so please study the documentation here before you start to whine. EFT is a child of FileDoor, the superb filetransfer manager, with was primary made for Qbbs, and which was later adapted by several utilities to Remote Access, too. Stig Jacobsen of DAK software was the original author and he had genius ideas on how to improve the rather primitive filetransfer system, and the (still) buggy protocol drivers build into Qbbs,RA and (too bad) SuperBBS, too. For most features the honor has to go to Stig, and I want to state here that I think he is a superb C programmer. For I'm primary a C programmer, too I will try to get in touch with him to see what four eyes can see better than two, besides I heard that he had stopped supporting FileDoor. Besides EFT is a completly different program and I neither had the sources of FileDoor nor I used toolboxes to create EFT. EFT is a piece of work from my own hands and brain only. Anyway FileDoor is one of the rare BBS utils, that I've found to be working very well and that were beta tested in a way all those superduper blabla version BBS utilities should get tested. (Hint!) Betas wanted! As EFT is growing we need more systems, that are willing to use EFT as their ONLY file transfer manager. We are interested in SBBS and RA systems not running US Robotics HST. Also EFT is searching for foreign support nodes outside Germany, with sysop with technical know-how, and the will to assist users and sysops of their country in the use and installation of EFT. Of course support nodes get their key for free and of course support nodes should not use any other transfer manager than EFT. If you are interested, you can contact me: Michael Raus II The Wizard's Inn II BBS Line1: ++49,2307,21968 HST DUAL V.32bis Line2: ++49,2307,10012 HST DUAL V.32bis Please direct all mail to 'System Operator' or 'SysOp'. EFT enhanced file transfer 07-03-91 11:23am Page 3 Evaluation keys will run for 60 days - that's 2 months! If you get a new beta version the 60 days start all over! After that you must buy a normal key which is avail for $20 US Dollars. Active betas pay less! The fastest way to get the key is to pay the money via TeleText/BTX to: The Wizard's Inn II BBS Volksbank Kamen-Werne EG Account/Konto: 501 64 64 400 Institute/BLZ: 443 613 42 You will get the key in an attached message at The Wizard's Inn right after the day your money arrived here. The normal key will work with all future versions of EFT, and the key information (BBS and Sysop's name) is shown at the top of each screen, so include this information with your money order so I can easily and fastly generate your personal key. If EFT sometimes gets completly rewritten or otherwise totally redesigned and enhanced you'll mabye have to pay an additional fee, but until now the $20 US dollars bring you the newset EFT version as long as you and your BBS may live... EFT enhanced file transfer 07-03-91 11:23am Page 4 2. Features ----------- As for you FileDoor users I've included the features of the original FileDoor, to show were I made changes to the original. o EFT's .CFG file doesn't require a FILEDOOR.PRM, and is 100% compatible with FileDoor! Simply replace the executables, rename the support files and there you are. Besides: If you want to take advantage of the enhanced features , you have to specify additional statements and parameters in your EFT.CFG o Up to 32 upload, and 32 download protocols may be installed. o Free files. If you use X_List <tm> you'll be aware of the concept. It is files that your users get "for free", i.e. downloading a free file won't be noted in the users total download. As an additional bonus EFT supports FILES.CTL, which is originally an reg. RA 1.0 only feature. You can use both methods at the same time. o Users can choose to automatically <G>oodbye after a file-transfer have completed. o You have 100% control over the protocols. Name them as you wish, include or exclude any you want. There are 5 types of interfacing methods, which should allow just about any stand-alone file-transfer program to be used with FileDoor, including DSZ and those protocols following the standard Opus interface for external protocols. Plus EFT's CDS support for the superb MPt protocol from Microtech Systems. o Private files (not seen by the users) can be uploaded for SysOp only, if the user supplies a '/' as the first character of the description. Plus EFT's privatedir support: Private files are moved across partitions to the directory you specify for private uploads, so your private files are not longer moved to FILES.BBS when the next household event is run. o When up-/down-loading, you can make EFT add a default- extension (ARC, ZIP, LZH, whatever you want..) if the user doesn't supply an extension. o If you use DSZ for ZModem uploads, a user can restart an aborted upload (after a carrier loss). This never worked correctly in FileDoor - it will work with EFT. If you define a protocol to be a able of resuming aborted transfers, EFT will swap in the aborted files to the temp upload directory across partitions and networks. EFT enhanced file transfer 07-03-91 11:23am Page 5 o Built-in FILESCNT. You have the option to update a "Download Counter" each time a file is downloaded, so that your callers can see what files are the most popular on your system. Plus the chance to define how your counters are to be separated from the remaining description. Do you like [] or {} or <> or even <] or or or ... o Special separate logfiles for uploaded and downloaded files. Plus advanced logging of filesize and CPS rate of the transfers! o Rejection of uploads of duplicate files (files that already exists on your system). Saves you tons of diskspace, and loads of online- time for your callers. Plus phonetic antiduper! Ever got angry upon users uploading XBTX_070.LZH even when there is XBTX_100.ZIP already somewhere on the board? The phonetic antiduper will keep track of those shitheads ... o Rejection of uploads of non-archived files. Same advantages as for the dupe rejection feature. Plus Instant Arc-Checking! Ever got angry on users uploading archives with CRC errors? EFT will check the received files immediately after they were received, and gives only credit to those files that are 100% ok. Plus rejection of .GIF files with too low resolutions or number of colors (so no longer CGA GIFs, that are older than my grandpa (and they are both already dead ...). Same goes for PCX files. o AutoSearch<tm> - Instead of just searching the current file-area, you can direct EFT to search all file-areas for the files that the caller have selected for downloading, and of course EFT keeps track of the security flags, the security level and the flags and level to private files in all of the areas, the user has access to. o And all the standard features that any decent Door program have: Monitors carrier Checks inactivity timeouts Checks time-limit/download-limit Runs in local mode with no special provisions Handles ansi/non-ansi users Variety of anti-hacker devices built-in Etc. Plus EFT's swapping DOS shell and the colored chat mode (active even in prompts, menus, menu files, warnings etc, and you leave the user at the same position you broke in with the chat!) using standard RA keystrokes for that you don't have to miss your standard BBS features when running EFT. o Sorry no FileDoor feature for this. EFT enhanced file transfer 07-03-91 11:23am Page 6 Plus advanced breakdir support: Generations of broken files may be kept, moving in the biggest of them when it comes to resuming. So even if there WAS a misunderstanding between the protocol driver, EFT and the BBS you can recover your file from the breakdir and do not have the fear of loosing files. If the resuming was successful you can direct EFT to delete all the old generations of the broken files from the break dir. o Sorry no FileDoor feature for this. Plus automatic network support: If EFT detects a shared environment, it begins to lock files that it is using, if a user is online, and some other process is using the logfile or something else that EFT needs, it tells the user of that circumstance and waits max 30 seconds for the other process to release the file. o Sorry no FileDoor feature for this. If the user drops carrier on receiving the descriptions of the received files, EFT will put in a definable message and moves only the good files to your fileareas to give users access to the new files. If the descriptions were given before the transfer EFT moves private files to the correct areas even if no carrier is active. o Sorry no FileDoor feature for this. You can have up to 6 behavior windows to let users download only during special times a day, and those windows can overlap 24/0 o'clock and themselves ... o Sorry no FileDoor feature for this. Full support of RA 1.0 BADFILES.CTL - giving Qbbs and Sbbs systems that feature, too. Plus support for BADFILES.ASC/.ANS. o Sorry no FileDoor feature for this. Full multiline support: You can have one shared CFG files for all the lines running EFT, with EFT replacing macros given in the paths with the real node paths. o Sorry no FileDoor feature for this. Foreign language support: As an additional feature EFT gives you the chance to define more than the two "Y" and "N" characters in Yes/No prompts, to make the use for national systems using menu files a little easier. o Sorry no FileDoor feature for this. "Download a special file" support for sending filelists etc.. Calling EFT with special parameters makes it asking the user for the procotl to use and sends him the specified file. o Sorry no FileDoor feature for this. EFT enhanced file transfer 07-03-91 11:23am Page 7 Support for password protected areas, files and file groups using both wildcards and paths. This is combinable with specific downloads and freefiles. Full control for those running user groups on their systems. o Sorry no FileDoor feature for this. This is my favorite: ALT-H with line noise simulation ;-) o Sorry no FileDoor feature for this. The new behavior statement: Make the protocols send the descriptions from your FILES.BBS along with the downloads (works with AutoSearch, too), collect descriptions from ASCII files being sent along with the uploads, FOSSIL support for init or deinit the FOSSIL when running protocol drivers which do their interrupt driven I/O themselves (Tmodem!), resuming aborted transfers and swapping in of the right files from any directory on any partition, OPUS 1.1x support, instant checking of uploaded archives of any style, designer errorlevels to run ill-behaving protocol drivers, a special way of running protocol drivers from batch files and still getting the right errorlevels, and much much more. o Sorry no FileDoor feature for this. Fullscreen file tagger! Users can klick on the files they want, can browse filelists up and down, sort them, search for files, show only new files etc.. This also works in a global mode, in that all fileareas, that the user has access to are combined to form one big list. The file tagger is capable of multitasking: He lets users select files while the tagger is still search the filebase for more files to add to the bottom of the list (see Norton Utils 5.x FileFind), and he lets users view the contents of archives. o Sorry no FileDoor feature for this. Fullscreen file browser! The tagger includes a full featured file browser, that works within archives, too! And its easy to use: If you want to open a file then EFT decides if it is an archive or not. If it is an archive EFT shows the directory of the archive, and if its not EFT show the contents of the file. You can scroll up, page down - jump to any location in the file. o Sorry no FileDoor feature for this. Automatic Intercomm/Bimodem interface for full-duplex protocols with complete limit/ratio check, file descriptions, file moving. Plus password proctected Bimodem sessions and private files support. o Sorry no FileDoor feature for this. EFT will update USERON.BBS, to exactly show a user or the sysop on a different line what the actual line is doing (FILE XFER, CHAT, DOOR). EFT enhanced file transfer 07-03-91 11:23am Page 8 o ok - can I stop the list? I'll describe the other features not mentioned here in detail later in the documentation ... 3. Requirements --------------- o An installed and working Remote Access of ANY version! EFT automatically adjusts to the new EXITINFO format. Sbbs is also supported, so if you run a Qbbs system and want to run EFT get an util to convert to RA or SBBS and there you are. Note that you also have to convert the config files as EFT reads some information from them. o Dos 3.0 or higher - you *may* be able to run EFT with Dos 2.x, but I haven't tried it myself. (You should upgrade to DOS 5.0, bozo) o One/more/several external transfer programs, such as DSZ, CLink, JModem, OMLink, Kermit, etc. - Whatever you desire! The transfer programs are NOT included with EFT for a very good reason: Just the seven protocols in use at my system occupy more than 200 kb on my harddisk altogether. Chances are that you have some of those protocols yourself, or that you can get them in newer versions than those that I have. o I do not know exactly how many RAM is minimum to run EFT. In fact at the time of writing this, EFT is not optimized yet. I run it under RA in 450k task (altogether with RA). I expect EFT to run in ca 150k of RAM. I'll see what can be done to reduce the RAM needed in one of the next versions. Anyway in most cases you'll have plenty of RAM after EFT has swapped out. o You may find EFT more useful, if you have a modem and a telephone-line handy, even though these items aren't required. And you should be connected to a energy source to put some life into your equipment ... EFT enhanced file transfer 07-03-91 11:23am Page 9 4. Installation --------------- Before installing the program, please read the documentation completely, and any READ.ME files supplied within the archive. The program is installed with a type 7 or type 15 command in each of your file menus. Type 7 is preferred, it is faster and simpler, but it also uses more memory, if you do not specify the *M memory swap feature. To get type 15 to work with EFT downloads, you must enable AutoSearch<tm> (described below). EFT supports the following parameters: 1. Command line parameters --------------------------- -p<n> ... defines the COM port to be used. <n> should be replaced by 1 for COM1 or 2 for COM2 etc. You should combine this with RA's *P macro: -p*P -p defaults to local mode (!!) if not given. -t<n> ... passes remaining time in minutes the user has left for being online today. If this is not given EFT calculates the remaining time from EXITINFO.BBS. You should combine this with RA's *T macro: -t*T -n<n> ... passes the number of the line EFT is working for. This is to enable EFT's multiline support, so unique filenames and directory names are used to prevent the lines to disturb each other. This should be combines with RA's *N macro: -n*N -a<path> ... specifies the path to the actual filearea from which files are downloaded or in which files are uploaded. A trailing backslash is not needed, EFT will add one for you if needed. WARNING!!! If you skip this parameter EFT will add the actual path to the end of the file areas. If you start EFT from your RA/SBBS system dir, everbody will be able to download your system directory! So be sure to set the -a parameter to an appropriate value! This should be combined with RA's *0 macro: -a*0 -w<password> ... Tells EFT that this area is password protected. As the first operation EFT asks the user for the password specified after the -w commandline parameter. 3 attempts are allowed then the user is returned to the BBS. Case does not matter. -c<path and name of config file> ... specifies the path and name of the file EFT has EFT enhanced file transfer 07-03-91 11:23am Page 10 to use as its .CFG file. This can also be in a shared directory for use by several lines. See also the $1 macro for pathnames in shared .CFG files. E.g.: -ceft.cfg or -cd:\bbs\1\eft.cf1 -du ... directs EFT to do uploading (u). Only the protocols defined in EFT.CFG as upload protocols are selectable. -du uses the path set by -a or if -a was not specified uses the actual directory from which EFT was started. -dd ... directs EFT to do downloading (d). Only the protocols defined in EFT.CFG as download protocols are selectable. -dd uses the -a path or the actual path or AutoSearch (see there). If you use AutoSearch you can omit -a. -dd<name of download file> ... directs EFT to transfer only that specific file. The user is asked for the protocol to use and the transfer is started. Useful to transfer filelists or hint files. Specific files can be password protected or can be free files, too! The path to the specific file is given via the -a parameter. The FileDoor switches '-h' and '-?' are not longer supported by EFT. You have the documentation for this. 2. Downloads ------------- The optional data field should be as follows for downloading: EFT.EXE -dd -a<downloadarea> -p*P -n*N *M The above example assumes that you have placed EFT.Cfg and EFT.Exe in the current directory. If EFT.EXE isn't in the current directory, you must specify the complete path to it (refer to the RA documentation). also in this example the .CFG file defaults to EFT.CFG in the actual directory. The '-dd' is a switch to tell EFT to "Do Downloading". The <downloadarea> is a complete path specification to the area that the user is going to be downloading from. Sample: -aC:\Files\QuickBBS\ You may omit or include the trailing backslash as you please or use the *0 macro for template paths (see RA.DOC). WARNING!!! If you skip this parameter EFT will use the actual path it was started from, sending the user all of your system files on request. Same goes for uploading, so be sure to give -a. 3. Uploads EFT enhanced file transfer 07-03-91 11:23am Page 11 ----------- Uploading is pretty much the same: EFT.EXE -du -a<uploadarea> -p*P -n*N *M The '-du' tells FileDoor to "Do Uploading". The <uploadarea> is the complete path to the upload file area. This parameter should always be given, even with AutoSearch - otherwise, EFT would place uploads in the directory it was started from. You can use RA's *0 macro for template paths. 4. FD_UPD,FILEDOOR.PRM ----------------------- FD_UPD is not needed anymore. Free up some disk space and delete it. FILEDOOR.PRM is not created anymore. Instead the EFT.CFG file is read every time EFT is called. It is for sure time consuming, but it takes only seconds to read and interpret the .CFG file, so I did not saw the need to compile it to a binary file. You can speed up the reading of EFT.CFG if you skip all the comments and the unwanted statements from it. Besides this will give you seconds in speed increase. EFT enhanced file transfer 07-03-91 11:23am Page 12 5. EFT.CFG, the configfile --------------------------- The configuration-file (usually named EFT.CFG) informs EFT about the setup of your system. You cannot run EFT without it, but there is a sample configuration-file included in the archive to ease the pain... You may include blank and comment lines in the configuration file, which are ignored. Comments are inserted by placing a '%' anywhere on the line - anything following a '%' is ignored. Case in not considered significant in the configuration-file, but you should be aware of that some transfer programs may be case sensitive - DSZ for instance. Keywords can only be repeated a fixed number of times (to save memory) - I'm not going to list the limits here, but if you repeat any keyword too many times ('Protocol' for instance) EFT will terminate with a friendly message stating what the maximum limit for this keyword is. This is also logged to the logfile. General note: For all the logfiles, you can set them to the printer if you wish (use PRN/LPT1, LPT2, etc. as the filename). NOTE! EFT doesn't check that the printer is ready, so if it runs out of paper, or a paper-jam occurs, your system will hang very well until you come around to answer the well-known "Abort, Retry, Ignore" prompt from Dos. Also you can use the $1 macro which is replaced with the number of the line EFT is working for. For sample uses of the keywords, please study the supplied .CFG file. The keywords currently allowed are: LogFile <path and name of logfile> ... This names the EFT logfile. Whenever a user transfers a file, EFT writes an entry to this file. If you don't include a logfile statement, then there won't be any logfile (goes to the NUL device). The statements in the logfile will follow the OPUS style for logfiles. Maybe there is a way to make the log look like a Qbbs/FD logfile in a later version. Colour and Color <ANSI ESC sequences> ... Two keywords that have the same meaning. The parameter describe which color to use where: file tagger filedates ! file tagger filesizes ! ! file tagger filenames ! ! ! highlite ! ! ! ! ! ! EFT enhanced file transfer 07-03-91 11:23am Page 13 lowlite! ! ! ! ! ! ! ! ! Colour [0;32m [1;33m [1;33m [1;35m [1;32m ... ... [1;36m [1;37m [1;37m [1;31;40m ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! file tagger area ! ! file tagger cursor ! file tagger tagged files file tagger filedescriptions These Ansi-colour strings are not to exceed 10 characters in length each, and are sent raw to the modem prefixed by a Esc character. You can find the color codes in your PC-Dos tech. ref. or in various files floating around on BBS'es. FreeFile <path and/or filename with or without wildcards> ... If you wish to have any "free files" available for downloading you name them here (one file per line - repeat the statement as many times as needed). A "free file" is a file that won't be noted in the users download. This could be your "AllFiles" list, the RA users manual, or any other file that you want to persuade your users to download. Free files can be a single file, like "FreeFile TIC_LIST.ARC". For single files, you cannot and should not specify a path. Free files can also be a wildcard specification, like "FreeFile C:\Files\Info\*.*". For wildcard specifications you can specify the entire path to the free files, otherwise the wildcard definition is relative to the actual used path. Maximum is 16 FreeFile statements, because EFT has full support for RA 1.0's FILES.CTL, described in the supportfiles section, those 16 statements are only to keep compatibility with FILEDOOR.CFG. Free files are shown on a special line at the last chance menu. Protocol ... This is kinda complicated and is described in detail below. PrivateUploads [<path to private uploads>] ... If this statement is enabled, your callers can make a "SysOp-only" upload, by supplying a '/' character as the first character of the uploaded files description. Private uploads are posted in the usual upload directory (as given on commandline) but the description of the uploaded file is posted in the file PFILES.BBS (P for private) in the upload directory, where it later can be screened by the EFT enhanced file transfer 07-03-91 11:23am Page 14 SysOp or users, that have access to private files in that area. If you specify an optional path behind the PrivateUploads statement private uploads and PFILES.BBS are not posted to then usual upload path but to the path specified. This works highspeed on one partition (only renaming those files to the new path), and across partitions (copying with maximum available copy buffers). DefaultExtension <fileextension, 3 chars max> ... This just names the extension that EFT will add to filenames if the user doesn't supply an extension. If you leave this statement out, EFT will not apply a default extension. UploadLog <path and name of logfile> ... With this keyword enabled, EFT will keep an extra log-file to which all uploads are logged. I save this logfile (unlike RA.LOG which is deleted when it gets too huge), so that if I later discover that a user uploaded a non- PD/ShareWare program, I can look into this file, and catch the guy. Logstyle is OPUS and size and CPS are logged, too. DownloadLog <path and name of logfile> ... Exactly the same thing as "UploadLog", but this one of course goes for downloads instead. You can set both to point to the same file if you wish. NoAreaNames ... While searching through your file areas, EFT will display the name of each area. For 2400 baud users this can be slow. NoAreaNames will only show dots instead od area names. FilesCount [<char for open brace> <char for close brace>] ... With this keyword enabled, EFT will count the times a files is downloaded from your system. It places that number at the beginning of the file descriptions in FILES.BBS or PFILES.BBS, so that your callers can see what files are the most popular on the system. You can define how EFT should separate this count from the rest of the description. As this operation may cause a slight increase in your caller phone-bill if you have hundreds of files in your FILES.BBS or PFILES.BBS I implemented a cached FILES.BBS updater, that uses up to 64k of I/O buffer for FILES.BBS processing. As my test showed this is lighting fast, and for that I let the FILES.BBS updater do additional maintenance to your FILES.BBS such as erasing double files etc. to keep FILES.BBS or PFILES.BBS respectively as beautiful as the SysOp himself. Use the EFT enhanced file transfer 07-03-91 11:23am Page 15 pipe symbol (|) to tell EFT where to begin with file descriptions. So if you use this example without modifications a FILES/PFILES.BBS line may look like: Example: Filescount > < | may produce: SCHNAGEL.GIF >000< Schnagelbaer eats fish Example: FilesCount < ] will cause the download counter in your FILES/PFILES.BBS to look like this: SCHNAGEL.ZIP <1] Picture of a chute dog WUPDICH.LZH <12] Curious stuff If you only specify FilesCount without the two additional parameters EFT's counters will default to []. In general when updating FILES.BBS EFT reads it, writes a temporary file named EFTFILES.1, deletes FILES/PFILES.BBS, and renames FILES.$$$ to FILES.BBS. This way, if EFT or your system crashes, you can still recover the original FILES/PFILES.BBS. NoArchiveCredit <percent> ... The argument to this statement is a percentage. If a caller uploads a file whose extension doesn't match any of those given in the 'ArchiveExtension' statements (below), EFT prints a message saying that he won't get full credit for the file, and then it proceeds to adjusting his credit by the above percentage. Say you have a "NoArchiveCredit 60" in the configuration-file. Then we have this caller who comes along and uploads the file "JUUHUU.COM" (very naughty!) which is 80 kb in size - EFT discovers that "COM" is not an archive extension, prints a message to enlighten the caller, and stubbornly decides that the caller only gets credited an upload of 48 kb (80 kb*60%). ArchiveExtension <3 chars extension> [<cmdline for arctest>] ... Each 'ArchiveExtension' statement supplies an extension that will let callers upload this kind of files without EFT getting upset. In addition if you give the second parameter, it is taken as the commandline when a file with this extension was received, and you enabled the instant arccheck feature for the used protocol using the behavior statement (see there). You can use $1 as a macro, which is replaced with the name of the actual uploaded file on EFT enhanced file transfer 07-03-91 11:23am Page 16 runtime. EFT searched the DOS path for the called program. You can also skip .EXE or .COM extension from the arctest commandline. You can also run batchfiles here to test the given archive's integrity. Use the *C macro, which is replaced with the name and path of the active command processor (EFT uses the COMSPEC environment variable for this, so be sure that your command processor sets it correctly). When running batchfiles with the *C macro EFT switched to goodfile handshaking, because the returned errorlevel from batchfiles is always zero, and so you get an OK even on bad archives. The solution is the mentioned goodfile handshake: Let your batchfile create a file called 'GOOD.', if it thinks that the archive is ok and should be moved to your fileareas. If you used the *C macro and EFT finds the file 'GOOD.' (which contents is ignored), is assumes that the batch run was successful and moves the tested archive to your filearea. If you do not use the *C macro EFT switches to standard errorlevel handshake (zero=successfull, non-zero=corrupted archive). This is powerful: Imagine running virus scanners here or you could put in your BBS headers or what ever you like: It's all automatic and its done right after the file appeared on your system (no need to wait until the next household event), so the next user who tries to download the archive, which was uploaded some minutes ago gets an archive without CRC errors and your BBS's commercials in it, and that's guaranteed! For those who wants to have different headerfiles for uploads to special areas, there is the *9 macro which is replaced by the number of the actual filearea padded to the with of the number of the used fileareas. Haeh?? Ok here is the example: EFT is working in filearea number 5, and e.g. 7 areas used: *9 will be replaced e.g. with '5' 19 areas used: *9 will be replaced e.g. with '05' 125 areas used: *9 will be replaced e.g. with '005' This is to correctly compare strings in batchfiles. See the sample batch, that is included in the package ... If arctest is enabled EFT will check the size of the file after executing the arctest commandline, and if the size is smaller than before then that size is given credit for. So if you want to strip those annoying, unwanted commercial files that some sysops put into their files, there wont be any credit to the uploader for those stripped files. For in my opinion everybody who puts commercials into files except in the archive header needs some kicks in the ass! EFT will strip them anyway - so don't put them in. CheckDupes ... EFT enhanced file transfer 07-03-91 11:23am Page 17 With this keyword enabled, EFT will do A.I. work in an attempt to avoid that your callers uploads files that already exists on the system. For non-batch uploads (i.e. XModem) EFT will scan all your file-areas as soon as the caller have entered the name of the file he is going to upload. If that file already exists on the system, EFT will print a message, and refuse to start the upload. For batch uploads (i.e. ZModem) EFT will offer the caller an opportunity to enter the filenames- before- the upload. If he chooses to enter the filenames immediately, EFT will scan the fileareas to check if any of the files to be uploaded already exists, and abort the upload if that is so. If the caller performs a batch upload w/o entering the filename(s) beforehand, EFT will scan the file-areas when the upload have been completed. If it is discovered that one of the files uploaded indeed -was- a duplicate, the caller will get no credit for this file. EFT scans all areas on the system, so not only those that the user has access to, and it does not use FILES/PFILES.BBS instead it retrieve its information on dupefiles from the directories. This is somewhat slow, but If you have orphans on your system (files not yet in FILES/PFILES..BBS), dupechecking would fail. NoSimilars ... This will engage the phonetic antiduper. EFT will check FILES/PFILES.BBS for files that sound (!) similar to the files the user had given for uploading. So if the user tries to send an older version of an utility, that is already somewhere on the board he will get a message stating that there may be a dupe conflict in that specific filearea ahead concerning that specific similar file with that specific description. He than has the chance to reenter the filename, ignore the warning or to abort the uploading. This interactive dupechecking is only done on areas the user has access to, so he won't get dupemessages on files residing in hidden areas ... After an upload completes the anti-duper checks again, but this he won't ask the user and won't check for similars, but for real dupes, so users have still a chance to upload a file even with a name similar to one of the file already on your board. AutoSearch ... Like PCBoard and others, EFT can automatically search all fileareas for the wanted files when a caller initiates a download session, instead of just the current file-area as with QBBS, Opus, etc. Though it takes longer time to find the files, it also is an advantage, as: o Your callers need not to worry about if they are in the EFT enhanced file transfer 07-03-91 11:23am Page 18 right area when starting the download. This is especially pleasant new users. o They can download several files from several areas at once. o Using EFT with AutoSearch installed as a type 15 menu command, requires far less memory than a type 7, as RA, EFT and an external file-transfer program need not to be in memory at the same time - AutoSearch is required if you use type 15 to run EFT from RA. To enable AutoSearch, you just leave out the third parameter (the file- area path) when installing EFT for downloading in your menus. Simply: "EFT.EXE EFT.CFG D" Or whatever it would look like on your system. There is also a keyword for it - `AutoSearch' - that you can put in the .CFG-file. Of course on doing AutoSearch EFT keeps track of the security levels, security flags and password protected areas, files and file groups. Please notice... Using AutoSearch places some responsibility on your shoulders - you should make sure that you have no duplicate filenames available for downloading. If you do, your callers will be severely confused when they try to download one of them.. DownloadHours <start hour of download allowed> <stop hour> This works pretty much like the downloadhours option in RACONFIG. The two hours given may span midnight. When a user tries to download outside hours, EFT will try to display the file DNLDHRS.A?? - If it can't find it, it'll just display a standard message to the user. You can have up to 6 behavior windows, which can overlap each other, switching on and off downloading during the day. TouchUploads ... Some transfer programs and some protocols (most batch-protocols - i.e. ZModem) preserves files date and time stamp when uploading. This is not always handy, as the <N>ew files function in RA won't be very accurate anymore. To fix this, EFT will `touch' (set files time-stamp to the current date & time) all uploaded files, if you enable this keyword. NoStatLine ... If you get upset by the way the status-line behaves (I would wonder, because I does not scroll of the screen like in FileDoor...), you can turn it off entirely by including this keyword in the configuration-file. EFT enhanced file transfer 07-03-91 11:23am Page 19 TempDrive ... Sometimes EFT needs to create a temporary file (i.e. when using `$3' in command-lines). With this keyword you can instruct it as to where to put these temporary files - If you use a ramdisk, it will speed FD a bit up sometimes - If you have a CD-Rom, you better tell FD to put temporary files on your hard drive! Use as follows: TempDrive <drive>:- Sample: "TempDrive C:". The default disk for temporary files is the disk from where EFT is started. FileDoorDir ... This names a directory where EFT will search for all its external support files (except the configuration-file). This includes DNLDHRS.A??, EFT_DOWN.A??, EFT_UP.A??, etc. If you don't use this statement, EFT will look in the current directory. For multiline this can be a shared directory. AskAnother [SWITCH] ... Will cause EFT to ask the user if he/she wants to perform another file-transfer after completing the previous one. If you put the optional parameter SWITCH on AskAnother's line users will be allowed to switch from upload to download mode and vice-versa. Of course limit checkers stay active when chacnging from upload mode to downloading. EFT will deny access if user is out of limit. MinSpace ... This gives the amount of diskspace that must be available on the upload-drive before EFT will allow an upload to be started. The default is 100k, be sure to leave some space for incoming mail for you Fido-Nets. Unwanted <filename with or without wildcards> ... "Unwanted <filename>" will make EFT delete the given file if found in the upload-directory (when an upload completes). This is handy to get rid of logfiles created by transfer programs. Wildcards are allowed. Desclen <max length of description for uploads> ... This one is to restrict the maximum length of descriptions. Minimum=10, Maximum=77, EFT automatically adjusts the maximum description length if FilesCount is enabled. MinBaud <minimum baudrate to use EFt> ... This is the minimum baudrate the user must have toro transfer files with EFT. EFT enhanced file transfer 07-03-91 11:23am Page 20 FreeRatio <Number of free files> <number of free kbytes> ... Allows download of a specified amount of files and kbytes until the ratio checkers are enabled. EFT will always allow a new user to take one file even if files ratio is 1:1 (else users have to upload first to get access to your files). CorrectKbytes <trigger level kbytes> <maximum reduce kbytes> ... Use this if you have users, who are used to take huge amounts of kbytes from your board, or send huge amounts of software to you. RA and SBBS are limited to 64M up and download kbytes. So if a user uploads 65M to you, RA and SBBS will do wrap around to uploaded kbytes=1M. This will surely confuse your ratio monitor device! EFT can correct this with CorrectKbytes enabled. EFT will only correct the users kbytes if his downloads or uploads exceed the value given to CorrectKbytes as the first parameter (called trigger level in kbytes). EFT will subtract as as much kbytes as given as the second parameter, - but only if possible! So if a user has taken 61000 kbytes and sent only 9876 kbytes, EFT will correct uploadsk to 0 and downloads to 60000-9876 kbytes. if a user has taken 62000 kbytes and sent 21000 kbytes, EFT will correct to uploads=11000 kbytes and downlaods=52000 kbytes. First parameter must be greater than second (logically)! TimeOut <number of seconds for timeout> ... This is the number of seconds a user is allowed to do nothing in a prompt. FileDoor used to print a warning message if a timeout was ahead "Are you there?", but that was not a real question and could confuse users, who answered that question typing in "Y" or "N". FileDoor then took that key as the response to the prompt causing the timeout, even to confuse the user once more. EFT will output beep signals every 2 seconds to the user and the console if a timeout is ahead to wake up the user instead of writing pseudo questions. (See also ShutUp statement) BreakDir <path of breakdir> ... This is the directory EFT will use for aborted transfers etc. This can be on any partitions since resume moves files across partition borders. On multiline systems this can be a shared directory. The default is the root dir of the drive EFT was started from, so you better give a different breakdir ... SwapDir <path and name of swapfile> [FORCED] This is the complete path and name of the swapfile to use for EFT. The $1 macro is avail replaced by the number of EFT enhanced file transfer 07-03-91 11:23am Page 21 the actual line EFT is working for. This should be on a fast medium. If you put the word FORCED as a second parameter on the SwapDir line, EFT will be forced to swap to disk, if it has to run in an environment, that is not stable when doing advanced swapping to RAm devices. Desc <Text for default description> This is the description EFT will put in for good uploads, if the user hang up on the 'give description' prompt. ShutUp ... Tells EFT not to echo ^G chars to the sysops console (useful for night operation or nervous SysOps). BadFiles <path and name of BADFILES.CTL> ... This if RA 1.0's BADFILES.CTL, which is fully supported by EFT: It is a FILES/PFILES.BBS style file with wildcards and paths allowed. All of the files matching a line in BADFILES.CTL (or whatever name you assign) are rejected by EFT and the user won't get credit for them. YesNo <YescharsNochars> ... This is for foreign languages: YesNo allows one parameter which is considered as consisting of two parts: The first half of the word given as the YesNo parameter are the key that are accepted as a positive respond to a "Yes/No" style prompt of EFT. Case does not matter, and of course the second half is for the negative responses. The default is "YN", which is always active. f RA 1.0's BADFILES.CTL, which is fully supported by EFT: It is a FILES/PFILES.BBS style file with wildcards and paths allowed. All of the files matching a line in BADFILES.CTL (or whatever name you assign) are rejected by EFT and the user won't get credit for them. Sample: YesNo OJNN Allows french and german responses, too. UploadCredit <timefactor> ... This enables EFT to give time spent on uploading back to the user. If you specify 1 as the timefactor users will not loose time if they sent something to your system. If you specify 2 they will gain time. Default is Off, means even uploads reduce the users time. KeepBroken ... This tells EFT to use unique names when moving files to the break dir. This prevents good files in the break dir EFT enhanced file transfer 07-03-91 11:23am Page 22 from being overwritten, and the SysOp can screen the break dir from time to time if there are useful files in it. If a user wishes to resume a transfer and resuming is enabled for the actual protocol driver EFT will move the biggest of a file generation from the break dir to the temp upload dir to let the proto driver resume the file. UnlinkBroken ... This tells EFT to erase all of the broken files with the name of the actual successfully received file from the break dir freeing up some disk space. Note that it is not the opposite of KeepBroken. MinGIF <Min X resolution> <Min Y resolution> <Min colors> ... This enables EFT to reject uploaded GIF files if they are below the specifies resolution and/or number of colors. No uploadcredit is given for those files. MinPCX <Min X resolution> <Min Y resolution> <Min colors> ... This enables EFT to reject uploaded PCX files if they are below the specifies resolution and/or number of colors. No uploadcredit is given for those files. LogStyle [OPUS] or [FRONTDOOR] or [SBBS] ... This describes how the logfile that EFT creates looks like. You can make it look like an OPUS or FRONTDOOR/QBBS logfile. LogLevel [RAW] or [MEDIUM] or [WELLDONE] ... This describes how much information EFT puts into the log. Default is WELLDONE for debugging purposes. InfoFile <name of FILES.EFT> or "<TIME>" ... If you are going to use GetInfos or SendInfos as the behavior of your protocol drivers, InfoFile gives you the opportunity to change the name of the file in which the BBS descriptions are sent along with the downloads, and from which upload descriptions are retrieved (if found). Neither wildcards nor paths are allowed. Max 12 chars. Note! Users must know which name you assigned to be used as the InfoFile, when you use the GetInfos behavior! A good place to put such information is either on the protocol selection menu or some of the help files. If you specify the word <TIME> (including the <> chars), EFT will generate a filename for you consisting of the day of week and time of the transfer, so if users do several transfers in a row, and use protocol drivers, that are not capable of renaming already existing files (or users have installed them wrong way), this is for you. EFT enhanced file transfer 07-03-91 11:23am Page 23 Example: SU012259.EFT (Sunday late night show ;-) InfoFileHeader <name and path of FILES.EFT-header file> ... If you are going to use SendInfos as a behavior of your protocol drivers, InfoFileHeader is the name and path of a file to put first into the infofile. This could contain special hints, commercials or infos on your system. UploadName ... Makes EFT add the name of the uploader to the descriptions of the uploaded files. Note that with UploadName enabled the description can grow above DescLen (see there). PICResolution ... Makes EFT add the resolution and number of colos to the descriptions of uploaded GIF and PCX files. Note that using PICResolution the description can grow above DescLen (see there). EmbeddedCodes ... This will enable EFT's support for embedded control codes used in support files. With this option set you can make EFT insert e.g. the users name or ratio on files or kilobytes downloaded or whatever you like everywhere you like in any of your display files like RATIO.ASC/ANS or EFT_UP.ASC/ANS. UseEGA ... EFT will automatically switch to 80x43 or 80x50 text mode if your BBS system already activated that screen mode when it runs EFT. In addition you can force EFT to use EGA/VGA resolution with this statement. Anyway EFT restores the original textmode on return to the BBS. AutoTransfer ... With AutoTransfer enabled EFT will allow your users to sent files with requested files or file to be uploaded wit their descriptions to your BBS to let EFT process them automatically as if the user had typed in all of the files. Of course this will work with the build in limit-checkers and dupe-checkers. In addition behaviour sendinfos and getinfos will work, too. AutoTransfer works great with automatic logons via terminalprogram scripts. Maxlimit <maximum download limit> ... This is to get around a bug in RA: If a user manages to get more k than his download limit allows (e.g. through Bimodem), RA passes a negative value EFT enhanced file transfer 07-03-91 11:23am Page 24 as the download limit (download_limit-transferred_kbytes is below zero!). RA defines the downloadlimit to be a non-negative integer, resulting in a downloadlimit of ca. 65000k ... users can take everything! If you specify your maximal download limit you grant to your users using MaxLimit, EFT can determine if a limit is invalid and will calculate the correct value. TagFiles [Minimum Baudrate] ... This enables the most complex feature of EFT: The full screen file-tagger: With this utility your users now can easily tag the files they want to download instead of remembering the files they saw on the BBS and typing in cryptic filenames. If AutoSearch is enabled, the tagger lets the user switch areas, and will show him how many files in which areas he selected already. Of course limit checking is done, private files are accessible in each area, access flags are processed, private security is processed, and all the other standard features EFT brings you. As a special bonus the file tagger gives your users a global area access which shows all areas (the user has access to) in one list to select files from. Users can switch to New-Files-Mode to list only the files, that arrived after he was last on. This works also with global area selection. File masks are selectable to show subsets, and a super fast cached quicksort gives the opportunity to sort the displayed list by name, size and date. Want more? Ok note this: To give your users maximum speed while processing even largest file systems on large file-based BBS (like mine) the file taggers works multitasking and lets the user select file WHILE THE TAGGER STILL COLLECTS files from your file base. That's it huh? To use these enhanced features, you hardly see on any other BBS your users must conform to a minimum of requirements: They must have ANSI enabled of course, and must use a terminal that offers more than 12 lines on the screen. The file protocol that the user selected has to be a batch protocol (tagging ONE single file is nonsense), and he must run at a minimum baudrate of that you specify as the parameter to the TagFiles statement. If you omit the parameter then users at any speeds are allowed to use the tagger. To give your users instant help you can use the related display files TAGGER.ASC/ANS. There are some hidden keys not mentioned on the taggers screen. You can include them in your help files: * and + scroll the filelist under the taggers cursor by one line up and down, and SPACE sorts the list again using the actual sort mode (no need to cycle through speed search feature. Pressing Control-A .. Control-Z searches for files that begin with the character A .. Z. The taggers cursor is positioned on the found file, or stays where he was. Example: To find the file EFT users EFT enhanced file transfer 07-03-91 11:23am Page 25 may enter ^E^F^T and whoops! the cursor sits on the file EFT.ZIP or maybe EFT.LZH or whatever have we. This works in global mode, too! Here is a list of all the file taggers commands, so you can easily make TAGGER.ANS: 7 8 9 move cursor close archive4 6open archive/ view file 1 2 3 A select area ? show online help M enter filemask K switch to keyword search D select display mode (All/New files) N enter date to search for new files F toggle private/public files (if private files there) S change sort mode SPACE sort list again T tag/untag files 5 tag/untag files ESC done, download files if selected R redraw screen * scroll list up + scroll list down You can not download files from archives yet, but you can view the contents of any file even files in archives! The tagger includes a fullscreen file browser, that lets you page through any file, by simply pressing '6'. EFT automatically determines if the file, the cursor is on is an archive or not. If it is EFT will show the direcotry of the archive and some technical information. If you press '6' again, EFT dearcs the file under the cursor and views it. If the file under the cursor was no archive EFT simply views its contents. This also is done in a multitasking way: EFT still collects and formats the file information while the use is viewing the file. Instant access! EFT supports all archive formats excluding LBR and MD formats. A word on archive managers: As modems are getting cheaper, it is my opinion to better download a complete file of say 200k in size with a transfer time of 2 minutes, than to extract one file from it in 1.5 minutes and download that for 1 additional minute. Viewing is ok, to determine which version is included in an archive, but extracting and recombining to new formats makes lesser sense than ever these days. Protocol <efficiency> <letter> <way> <maxfiles> <name> ... General information This is what EFt is for: It describes the external EFT enhanced file transfer 07-03-91 11:23am Page 26 protocols that are driven by EFT. I've included every protocol I could think of in the supplied example .CFG file, so you might be able to get away with not modifying these statements at all (other than commenting out the protocols that you don't want to support). Ok, ready? - Every protocol statement is composed of two or three lines (the third is optional). The first line introduces the statement, supplies various parameters and names the protocol. The second line contains an interfacing method and after that follows the complete commandline which is passed to Dos when executing the external file transfer program, after some macros, that you can use in the commandline are replaced. The protocol line The first line has the following format: Protocol <efficiency> <letter> <way> <maxfiles> <name> o 'Protocol' is just the keyword. o '<efficiency>' is a percentage that states the efficiency of this protocol. It will in most cases be around 75-95 %. For interfacing method 'Other' (described below) you should be very careful to set the efficiency to the correct value. (It will be better to set it too high, than too low). o '<letter>' is the letter that the user types to select this protocol. o '<way>' is a single letter - 'U' tells EFT that this is an upload- protocol, and 'D' tells that it is a download-protocol. o '<maxfiles>' is a number stating that maximum number of files that can be transferred with this protocol in one session. For non-batch protocols (i.e. XModem) you must specify '1' and the user must supply the filename and description of the file before starting an upload. For batch protocols (i.e. ZModem) you can specify any appropriate number (no longer max 20 as in FileDoor). For batch-protocols that must have all filenames supplied on the commandline (i.e. Clink), you may want to limit the number of files to 8 or less (4 or less with AutoSearch<tm> enabled - read the "Commandline overflow" section below). o '<name>' is the name of this protocol and what the user sees on the list of protocols when selecting protocol. This free format text may be up to 70 characters long. EFT enhanced file transfer 07-03-91 11:23am Page 27 The interface line Now for line two in the protocol statement. On this line we have a protocol sub-type, a space character, followed by the actual commandline passed to Dos when starting the transfer. It has the following format: <method> <commandline with macros> o <method> describes the way EFT will talk to the installed proto drivers, and how EFT calls the drivers. EFT supports the following methods of interfacing: DSZ ... This protocol uses the DSZ file transfer program by Omen Tech. I've tested this with almost all the DSZ protocols, using the 161290 revision of DSZ. It tells EFT that the protocol driver writes a DSZ compatible logfile, and that it should be used to determine what files were correctly transferred and which not. For this to function correctly DSZ requires that you set an environment variable called DSZLOG in your batchfile, that runs your BBS. Use somewhat like this sample: SET DSZLOG=d:\bbs\dsz.log This could be a shared directory and EFT will handle the concurrent access to that file. If you don't specify that environment variable EFT will use its default DSZ.LOG, and for this has no path it assumes the logfile to be in the temporary up/download directory that EFT creates before calling the DSZ compatible driver. Besides DSZ stops logging at all if it can not find this environment variable, so strange things can happen... Opus ... This protocol follows the Opus 1.0/1.1x conventions for external file transfer protocols. I've tested this with the Kermit and MegaLink protocols. For Opus protocols, you may not give any commandline parameters - The format of this is fixed with this protocol type, and EFT will automatically set it up. To decide between OPUS 1.0 and OPUS 1.1x conventions use the behavior statement OPUS11X (see there). ErrorLevel ... EFT enhanced file transfer 07-03-91 11:23am Page 28 This simply means, that if the file transfer program exits with errorlevel 0, then EFT assumes the files (all of them) were sent. If non- zero, then none of the files were sent. On batch uploads you can perfectionize this with the behavior statement arctest (see there), so EFT will have a chance to divide the good from the bad uploads. Also see the 'errorlevel' behavior statement. .np4. Other Other ... This indicates a protocol type which does not create any sensible log, and which does not exit with any sensible errorlevel when done. This type is handled in an extremely kludgy and simple way: EFT calculates how long it SHOULD take to send the files (based on file size, baud rate and efficiency). Then it gets the time from Dos, and starts the transfer program. When the transfer program returns to EFT, it looks at the time again. If the transfer program was running for the amount of time just calculated, EFT assumes that all files were sent as expected. If not, EFT assumes that no files were sent. Therefore, you should be careful to set the efficiency for this protocol to the proper value.. This is the *worst* way of doing it, and you should only use 'Other' type protocols if you really have to. You can use the arctest statement to optimize uploads with this kind of drivers. CDS ... This is the Call-Data-Specification method used by newer protocol drivers like the superb MPt protocol from Microtech systems. Like the DSZ method it communicates with the driver via a logfile. You must either specify an environment variable called CDSLOG like: SET CDSLOG=d:\bbs\cds.log or use the EFT default 'CDS.LOG'. Note that there is no path given and the CDS logfile is created in the temporary up/download directories. Another way to tell the driver (not EFT) what log to use is via special install program supplied with the driver itself. For MPt use Mptset to set the correct name for the CDS log file. MPt allows either CDS or DSZ logging. You should prefer CDS logging for it is safer and provides more information than the older DSZ log format. Make sure that you set the EFT path to the CDS logfile to the same file as in the drivers setup. EFT enhanced file transfer 07-03-91 11:23am Page 29 INTERCOMM ... This if the logstyle Bimodem uses. Instead of implementing a static interface special to Bimodem from Erik Labs, I decided to do it a more general way. EFT does not know that it drives Bimodem, it simply knows that it has a protocol that uses an intercomm-style log and is capable of fullduplex transfers. So if the future brings a second full-duplex protocol with intercom logging ... EFT is ready to drive it. Have a look at EFT.CFG to get an idea how the parameters work to drive Bimodem the right way. Eft does checking for received files on downloading and processes downloads in upload mode. It passes time and byte limits on the commandline to bimodem and will get the right file descriptions from the intercom file. Of course the Bimodem-received descriptions are truncated to desclen length, and EFT takes care of the minimum length, retrieving a longer description from the user if the received one is too short or invalid. GIF resolution and the name of the uploader are added if enabled via GIFresolution and UploadName. You can define the name and path of the intercomm-style logfile to meet your needs. Simply use a environment variable SET ICOMLOG=InterCom.Log or similar. Normally you should point the intercom path to the temporary upload/download dir by simply skipping the path information. EFT will use a default value of "INTERCOM.LOG" if you simply do not set the environment variable. EFT will create a BIMODEM.PTH style file automatically in the temporary upload/download dir, which tells Bimodem what files to transfer. EFT will use the default value of "BIMODEM.PTH" as the path and filename, until you specify a different path using the SET BIPATH= environment variable. I recommend you to use the default value by simply skipping the environment variable, but its possible. Third Bimodem has to know from which pathes it is allowed to send files. EFT will create a file called "BIMODEM.DIR" in the temporary upload dir containing the pathes of the fileareas that are available to the user. Note that a filearea is only allowed if normal and private level and flag setting meet the users settings. You can use SET BIDIRS= to create an environment variable to let EFT create the file under a different name in a different path. EFT enhanced file transfer 07-03-91 11:23am Page 30 Forth EFT is able of generating password files for Bimodem, so no user will get password protected files by adding then to the Bimodem transfer list while transfer is running. If You use *W on Bimodem's command line in EFT.CFG, EFT will generate this file in the temporary upload dir, which is best, or under the path and name you define using the BIPASS environment variable. As for all of these environment variables you can use $1 in the pathes. EFT will replace this with the actual node number EFT is working for. Great for multiline environments with shared EFT.CFG. There are four macros to paste the information onto the Bimodem commandline: *A posts the contents of BIPATH, *D posts BIDIRS, *W posts BIPASS and *I posts the contents of the ICOMLOG environment variable onto the commandline (or the default values if you did not use the environment variables). Bimodem has the capability to check uploaded files against a file of pathes. This plain textfile should contain all of the filepathes of all of your areas, as no file is sent from those pathes, but you won't like to have files that already reside in one of those pathes. As this is a nearly static files EFT will not create it. Instead you must if you want Bimodem to do this. Otherwise simply skip the /J?:\path\file.ext parameter from EFT.CFG. TIP: One thing to remember: If users are out of download limit, they are still allowed to upload via Bimodem. Make sure to put a /S1 parameter on Bimodem's commandline in EFT.CFG for upload mode. This will prevent Bimodem from accepting added download requests while upload transfer is in progress. (Users - some of them are smart!) o <commandline with macros> is the command line which EFT uses to run your external protocol driver. If the file with the driver isn't found in the given directory EFT will search the DOS path for it. It will also automatically search for a .EXE or .COM version of the file, so you can omit the extension. As stated you have several macros which are replaced with information describing the runtime situation: o $1 or *P ... the actual used port (1=COM1) o *O ... the actual used port minus one EFT enhanced file transfer 07-03-91 11:23am Page 31 (0=COM1), if you have a protocol driver that takes 0 as COM1: o $2 or *B ... the actual baud rate o $3 ... the response file for DSZ or compatible drivers o $4 ... a list of the files to be transferred with full paths, so you better restrict the maximum number of files to be transferred with this macro to prevent a commandline overflow. o *C ... complete path and name of the active command processor (great to run batch files etc. see also behavior 'goodfile') o *H ... placing *H somewhere on the commandline tells EFT to leave the FOSSIL driver HOT (initialized) on shelling to the protocol driver. Otherwise the FOSSIL is deactivated each time EFT calls up a child program. EFT initializes the FOSSIL on return from the child process in any situation. o *N ... the actual node/line number o *T ... user's time limit in minutes o *S ... user's downlaod limit in bytes o *K ... user's download limit in kilobytes o *A ... contents of BIPATH environment variable or default "BIMODEM.PTH" o *D ... contents of BIDIRS environment variable or default "BIMODEM.DIR" o *W ... contents of BIPASS environment variable or default "BIMODEM.PWD" o *I ... contents of ICOMLOG environment variable or default "INTERCOM.LOG" The behavior line EFT introduces a third line to the protocol statement. This line describes special abilities of that specific driver. Here are the legal statements for the behavior EFT enhanced file transfer 07-03-91 11:23am Page 32 line: o ArcTest ... this is for upload protocols only, and tells EFT to test an uploaded archive for integrity before giving credit to the user. This may take a little while depending on the quality of the used archiver, but as the result you won't have broken archives on your board then saving lots of flame messages to the busy SysOp. Arctest works together with ArchiveExtension: It uses the additional commandline information you specify on the ArchiveExtension line to run the appropriate archiver. Any $1 macro on that commandline is replaced with the actual filename of the file to test. The remote user will only see a "Checking JohnDoe.Zip ..." prompt and as the result a "GOOD" or "BAD". On your local console you will see the complete testing run, and the screen may scroll upward if there are many files in that archive. EFT will restore the screen after checking for you so you see what the remote user sees. BEWARE! Some archivers use to output prompts on special occasions when they test archives. Be sure to switch off any interactive prompting while checking an archive. See also ArchiveExtension statement. o ErrorLevel=<good errorlevel> ... this is for up and download protocols that use the errorlevel interfacing method to talk to BBS systems. You can define what errorlevel should be taken as a positive result from the protocol driver. So if some weird driver return a non-zero errorlevel on a successful transfer you can now also use it with EFT. Errorlevel cannot be used in conjunction with the following goodfile statement. Note! Do not mix up the errorlevel statement for the interfacing method with the errorlevel statement on the behavior line! o GoodFile=<path and name of goodfile> ... As a unique new feature EFT introduces to chance to run protocol drivers from batchfiles. You may say "Big deal" ... but think of this: You can now run any driver even those which need special conversion to be taken or interaction-files to be created. Anything is possible now, even on return from the driver: You could run a virus scanner on your uploads, or archiver on arced or non arced files, you can run special utilities that extract descriptions from the uploaded files, place them EFT enhanced file transfer 07-03-91 11:23am Page 33 in a file called FILES.EFT and they will be automatically processed by EFT (see support files section). This is great for .MOD or .GIF style files! As I said: Do anything you want in your batchfile and if you find that the files are all correct you simply let the batchfile create the file you specified behind the goodfile statement. You can use any name for the goodfile and also any path e.g. if you have some sort of ramdrive. If on return EFT finds a file of the name and path, it assumes the complete transfer to be good and charges on downloads and gives credit on uploads. If such a file cannot be found then EFT assumes the complete transfer to be bad. Note that you can not use it in conjunction with the behavior errorlevel statement. You should use the goodfile statement in conjunction with the *C macro on the interface line. o Opus11X ... This is to run protocol drivers that use the OPUS method of interfacing and are written for OPUS 1.1x systems. EFT will perform special necessary operations and will give additional commandline parameters. o SendInfos ... Your users are gonna like this one: Now they get a textfile with all the descriptions of the files they requested for downloading. The descriptions are taken from the FILES/PFILES.BBS in each area and this works with autosearch, too. They are all placed in a file called FILES.EFT, which includes also information on which files were skipped because or downloadlimit, ratio, timelimit or password errors. FILES.EFT is always a FreeFile, so noone has to complain that he is getting charged for stuff he did not request from your board. SendInfos is of course only possible for download protocols. See also InfoFile statement. o GetInfos ... Your users are gonna like this one, too: It is the opposite of Sendinfos and allows the user to send FILES.EFT along with their uploads. If EFT finds a file called FILES.EFT in the temporary upload directory and SendInfos is enabled, it will try to get the descriptions for the uploaded files from that file. If a descriptions is invalid (e.g. too short) the user will be prompted for that description with the FILES.EFT description given as a default value which he can EFT enhanced file transfer 07-03-91 11:23am Page 34 alter. This is great for users that send huge amounts of files or for those who put up a huge upload and go to bed, because after completing an upload EFT will timeout normally and the BBS will do the same ... If you do not enable GetInfos, and the user send a file called FILES.EFT as an upload it will be processed as any uploaded file. See also InfoFile statement. o NoLeading@ This skips the leading @ character from the $3 response file on the interface line. So you can also run drivers, that support response files, but do not like @ characters in the filename. Beware DSZ and MPt need a leading @ character in their responsefile. o Resume On uploading this statement makes EFT swap in broken files from the specified breakdir to the temporary upload directory, so that the external driver can resume the transfer, if you run a multiline system this should be a shared directory so that users can resume transfers from line 1 on line 100, too. EFT will give a message to the remote user that it is swapping in file for him to resume, and enables a special hint on the 'give filename to upload' prompt, because swapping in of files can only be done if the names of the files to be uploaded are known to EFT. Always the biggest file of a generation of broken files is swapped into the temporary upload directory. o Cls When running the external driver the statusline may get overwritten when the output from the driver isn't formatted (like DSZ). To avoid this you can tell EFT to clear the screen when shelling, to let room for the drivers information. o Window=UpperLeft_X,UpperLeft_Y,LowerRight_X, LowerRight_Y,Attribute EFT introduces the unique feature to run external protocol drivers in a window! This is especial useful if you let EFT run drivers, that use DOS for their screen-I/O, and that have some sort or unformatted output (like DSZ). You can specify the coordinates of the window and the screen EFT enhanced file transfer 07-03-91 11:23am Page 35 attribute in which the driver should appear on the screen. This works perfectly with the three swapping methods (see there), and you can also use windows when you do arctesting (see behaviour statement Arctest). Note that SysOp-DOS-shells via ALT-J are never windowed. o ArcWindow=UpperLeft_X,UpperLeft_Y,LowerRight_X, LowerRight_Y,Attribute ArcWindow defines the window for arctesting (see behaviour ArcTest). So you can have a non-windowed file transfer but a windowed arc checker. o SlowBIOS Running external drivers in a window can cause interrupt problems on machines with slow video BIOSs. Thos BIOSs disable interrupts too long, causing data loss at the serial port. If you enable SlowBIOS, EFT will keep track of the drivers output and its interrupt activity switching RTS on and off as the driver writes to the screen or lets the screen scroll upwards. This is only needed on uploads to your systems, that are faster than 14400 bps in conection with the slow machines BIOS. o LeaveUploads This is to let drivers receive uploads to different pathes than the temporary upload dir. EFT retrieves the path information from the driver's log, and will find and move the uploads even if they are not received to EFT's temp dir. Enabling LeaveUploads makes EFT to let the uploads where they were received. EFT then creates/updates PFILES.BBS/FILES.BBS in the receive path. Credit is still given. If LeaveUploads is not enabled all uploads are moved to the actual filearea. Useful to establish a 'general upload' file area. o NofilesOK This is for drivers, that handle file requests internally (like Bimodem does it on request). Users are allowed to press Enter at the 'what file do you want to download'-prompt, to let the EFT enhanced file transfer 07-03-91 11:23am Page 36 driver handle it. EFT enhanced file transfer 07-03-91 11:23am Page 37 6. Supported files ------------------- EFT supports some of the various files that RA uses to output sysop definable texts to the user. EFT has also some files of its own which use is FileDoor compatible. Here is the list of the files you can install in EFT. Simply create a file in your RA TXTFILES directory with the extension .ASC for non-ansi users, and .ANS for ansi users: System files System files control special parameters and attributes of your system. They must reside in your RA system directory. FILES.CTL ... FILES.CTL contains information on files in your filebase: It allows you to mark any downloadable file on your system as free and/or password protected. The format of this file is: <filespec> [/FREE] [/PWD=xxx] Example: \RAFILES\EFT_100.ZIP /FREE \RABETAS\RABETA.ZIP /FREE /PWD=RACCESS If you do not give a pathname the path will be relative to the actual filearea. Here, EFT_100.ZIP is free. Downloading it will not affect the user's download statistics. Note that even though the file is free in this regard, the user must still have enough time remaining for the download. You can also use the FreeFile statement in EFT.CFG! RABETA.ZIP is both free and password protected with the password RACCESS. The user must supply the correct password before being allowed to proceed with the download. Passwords are case insensitive and not a maximum of 15 characters in length but instead passwords can be 255 chars long. Both features work with 'download specific file' (see -dd<file> switch in the command line section). Free files are shown on a special line at the last chance menu. BADFILES.CTL ... This file allows you to specify a list of files that users may not upload. Simply specify one file per line EFT enhanced file transfer 07-03-91 11:23am Page 38 (wildcards and paths valid), for example: *.GIF NORTON*.* c:\der\plums\sack\geht.um Would not allow any files matching either of these two patterns to be uploaded. TIP: On my board I have the problem, that every time I erase old stuff from the fileareas, users upload it again several days later because the dupe checker does not find any file(s) of that name(s) any more. So I did the following: I created a special directory called d:\unwanted and everytime I delete stuff from the board I do not erase it at once: I hurl it to that 'unwanted' area, so that the FILES.BBS of that area gets the entries. Later I erase the files from the unwanted directory (beware not to erase FILES.BBS!). So the anti duper will search the hidden unwanted area and will reject any file that is contained in the FILES.BBS. You can also use the phonetic anti duper with this, and if you set the security levels appropriately the anti duper my not ask the user if files in the unwanted area are real dupes, instead he will say "file exists" and thats all ... LIMITS.CTL ... This file allows you to specify, for each security level, a daily time limit, file download limit for each baud rate, and optional file ratios, either in number of uploads to number of downloads, or in total kilobytes uploaded to total kilobytes downloaded. The format of the file is as follows: <Sec> <Time> <300> [1200] [2400] [4800] [9600] or: <Sec> <Time> <300> <1200> <2400> <4800> <9600> <R#> [RK] Where <Sec> is the security level, <Time> is the daily time limit, <300> to <9600> are respective download limits depending on what baud rate the user calls at. <R#> is the ratio of uploads to downloads, and [RK] is the ratio of uploads in K to downloads in K. If you only specify a download limit for say 300, 1200 and 2400 baud, the download limits for the higher baud rates default to the highest baud rate specified, in this case the limit set for 2400 baud. If you specify a ratio by number (R#) value, then the user will be required to upload one file for every n they download. Similarly, setting the ratio by K will allow the user to download only the specified kilobytes of files per EFT enhanced file transfer 07-03-91 11:23am Page 39 1 kilobyte uploaded. This is fairly complicated, so look at this example LIMITS.CTL: 5 35 0 10 60 100 200 350 650 900 5 10 20 90 150 250 470 750 900 5 30 120 250 400 600 900 1200 50 300 900 Security level 5 entitles the user to 35 minutes per day, but no downloads. Security level 10 entitles the user to 60 minutes per day, 100k of downloads at 300 baud, 200k at 1200 baud, 350k at 2400 baud, 650k at 4800 baud, and 900k at 9600 baud or faster. In addition, the user must upload at least one file for every five downloaded, and may not download more than ten times the total size of files uploaded. Security level 20 entitles the user to 90 minutes per day, 150k of downloads at 300 baud, 250k at 1200 baud, 470k at 2400 baud, 750k at 4800 baud and 900k at 9600 baud or faster. In addition, the user may only download five times the number of files he/she uploaded. Security level 30 entitles the user to 120 minutes per day, 250k of downloads at 300 baud, 400k at 1200 baud, 600k at 2400 baud, 900k at 4800 baud and 1,200k at 9600 baud or faster. There are no ratio restrictions. Security level 50 entitles the user to 300 minutes per day, and 900k of downloads at all speeds without any ratio restrictions. FLSEARCH.CTL ... Unless you tell EFT to use this, it is not needed any more and ignored by EFT. Feel free to free up some diskspace and delete it. FILES.EFT ... If you use SendInfos or GetInfos on your behavior lines, the descriptions are taken from this file which is created in the temporary download directory, and is received with uploads to the temporary upload directory. You can set the name of this file to any name you like (maybe your BBS name) using the InfoFile statement in EFT.CFG. EFT enhanced file transfer 07-03-91 11:23am Page 40 Display files I call files which replace standard messages and prompts that are hardcoded into RA and EFT. You can mostly have two versions of a display file: One for users using ansi on your board, and one for those with don't. If EFT doesn't find an ANS file for some prompt,but does find the ASC alternative, then EFT sends the ASC file instead. If that can't be found either, it uses the hardcoded default message. Note that ONLY the following embedded control codes are active when sending those files. EFT will treat all embedded codes not listed here as normal characters, and will send them unmodified to the remote site. These codes are only active if you enable the EmbeddedCodes statement in EFT.CFG (see there). This is to keep the descrease in speed as small as possible on systems, that make no use of any embedded control codes. Neither does EFT send screen clearing codes at the beginning of a display file nor does EFT insert a Press [Enter] to continue pause at the end of a dispaly file. You will have to program that via CTRL-L and CTRL-A. This is for added flexibility. Character ASCII# Combination Information displayed ------ ----------- --------------------------------------- 65 ^FA Users full name 66 ^FB Location 67 ^FC Password 68 ^FD Business/Data phone number 69 ^FE Voice/Home phone number 70 ^FF Date of last call 71 ^FG Time of last call 79 ^FO Security level 80 ^FP Total calls to the BBS 81 ^FQ Number of uploads 82 ^FR Kilobytes of uploads 83 ^FS Number of downloads 84 ^FT Kilobytes of downloads 85 ^FU Minutes used today 87 ^FW First name only 51 ^F3 Handle (empty on RA004 systems) 52 ^F4 Date of first call 53 ^F5 Date of birth 54 ^F6 Subscription expiry date 57 ^F9 File ratio (number of files) 58 ^F: File ratio (kilobytes) 65 ^KA Total system calls 66 ^KB Last caller (any line) 70 ^KF Number of times user has paged sysop 73 ^KI Actual time (HH:MM:SS) 79 ^KO Time Remaining in minutes 81 ^KQ Daily time limit 82 ^KR Current baud rate 84 ^KT Daily download limit (in K) 87 ^KW Line number (as set on command line) 88 ^KX TERMINATES THE CALL 90 ^KZ Name of current template file area 50 ^K2 Number of current template file area EFT enhanced file transfer 07-03-91 11:23am Page 41 01 ^A Wait until the [Return] key is pressed 02 ^B Disable aborting with the "S" key 03 ^C Enable aborting with the "S" key 04 ^D Enable the "Continue?" prompt 05 ^E Disable the "Continue?" prompt 23 ^W Pause for one second HLP_UP.A??,HLP_DOWN.A?? ... This file is sent if a user types '?' in the protocol selection menu. Depending on if the user is up or downloading, HLP_UP.A?? or HLP_DOWN.A?? are used. These files are quiet similar to the XFERHELP.A?? file which RA uses, and in fact if EFT does not find its special files for up and downloading, it uses the general protocol information from RA's XFERHELP.A??. If XFERHELP.A?? could not be found either the '?' menu topic will be disabled, and the user will get a nasty beep if he typed '?'anyway (as for all illegal keys). The files should all contain information on the installed protocols. HLP_CMD.A?? ... This file is sent if a user types '/?' on the download files commandline. I should contain general information on downloading from your board, using the file tagger, request lists and other features. EFT_UP.A??,EFT_DOWN.A?? ... You can replace the hard coded protocol selection menu with these files. Note! EFT does not sent a trailing newline after those files. This is to let the cursor stay where the last ANSI sequence in the .ANS versions had positioned it. So make sure that you have an additional newline in your .ASC versions. Those files were named FD_UP.A?? and FD_DOWN.A?? in FileDoor! UPHINTS.A??,DWNHINTS.A?? ... You can replace the hard coded hints, that are shown after the user selected the protocol with these files. Cursor is left were you put it. On uploading a Filename 1: prompt follows this file, on downloading filenames are accepted immediately after the last character of the file is sent. EFT_CMD.A?? ... This file enables the /? topic on the 'enter files to download' prompt. If its found and sent the users gets information on how to enter downloads, what to consider on downloading, on autosearch etc. If it is not found the /? prompt will not be displayed, and will not be active. EFT enhanced file transfer 07-03-91 11:23am Page 42 File was called HLP_CMD.A?? in FileDoor. BADFILES.A?? ... This file is displayed if the user attempts to upload a file that is listed in BADFILES.CTL. DNLDHRS.A?? ... This file is displayed if a user attempts a download outside the allowed hours as defined in EFT.CFG. RATIO.A?? ... This file is displayed if the user tries to do a download which would exceed his/her ratio of number of files. Note! If you use this no additional information will be shown to the user (how many files, and which files exceeded the ratio). However the user will be asked after a 'Press [Enter] to continue' prompt, if he wants to transfer the remaining files. This is of course only useful for downloads. RATIOK.A?? ... This file is displayed if the user tries to do a download which would exceed his/her ratio of K of uploads to K of downloads. Note! If you use this no additional information will be shown to the user (how many files, and which files exceeded the ratio). However the user will be asked after a 'Press [Enter] to continue' prompt, if he wants to transfer the remaining files. This is of course only useful for downloads. TOOSLOW.A?? ... This file is displayed if a user tries to log on at a speed lower than the minimum required to log on to your system as defined in EFT.CFG. STARTCHT.A??,ENDCHT.A?? ... STARTCHT.A?? is displayed when the sysop breaks in for a chat via ALT-C. ENDCHT.A?? is displayed when the sysop terminates chat mode. TODAYK.A?? ... This file is displayed if the user attempts a download which would exceed his/her daily download limit. Note! If you specify this no additional information will be given (how many files, and which files exceeded the ratio), because the hardcoded routines will not be used. PWDERROR.A?? ... EFT enhanced file transfer 07-03-91 11:23am Page 43 This file is displayed if the user attempts to access protected files, and did not know the correct passwords. TAGGER.A?? ... This file is displayed if the user selects the ? key on the file taggers menus. Users must have ANSI enabled to use the tagger, but TAGGER.ASC is valid and processed anyway. EFT enhanced file transfer 07-03-91 11:23am Page 44 7. Samples,Notes ----------------- Ok, to avoid you run screaming away, I better show some samples: 1. Commandline Samples EFT.EXE Depending on if EXITINFO.BBS could be found EFT will perform two things: 1) If EXITINFO was not found, EFT brings up the local test mode. In this mode it will act like if a user is online, except it will not write any EXITINFO.BBS. Try chatting with yourself etc. everything works. 2) If EXITINFO was found EFT will assume some default because you did not give any additional parameters: o COM1: is used, o time remaining is calculated from EXITINFO.BBS o AutoSearch is enabled and EFT performs a download o the configfile defaults to EFT.CFG and but be in the actual directory EFT.EXE -cC:\FileDoor\MyConfig.Cfg -ddc:\schnupf.zip -wtest Perform download of the specific file C:\SCHNUPF.ZIP. Additionally the user has to give the password 'TEST' to get it. COM1: will be used, and the baudrate is determined from EXITINFO.BBS. EFT.EXE -du -a*0 -p*P -b*B -t*T *M Performs an upload to a RA system. This takes advantage of RA's commandline macros. I use this one to upload to my board using template paths (see RA doc). EFT.EXE -dd -a*0 -p*P -b*B -t*T -wmikesmegas *M Performs download from a RA system using the actual template filearea. Additionally the user has to give the password 'MIKESMEGAS' to get any byte from the board. 2. General Notes 1. HotKeys ... EFT brings the SysOp the following hotkeys: ALT-C ... chatmode with colors (ANSI only) and EFT enhanced file transfer 07-03-91 11:23am Page 45 automatic word wrap. On return EFT stays right where you pressed the key, so this will work in textfiles, menus, prompts or wherever EFT may be when you want to chat. ALT-H ... hangs up on the user with line-noise simulation ALT-J ... swapped DOS shell, returns to exactly the position you pressed the key. Availiable everywhere in EFT. Automatic use of XMS/EMS memory. 2. Networks ... EFT will support networks that use SHARE.EXE to access files from different sides. It will detect SHARE and switch to locking mode automatically. Note that some drivers do not support shared access to log files etc. E.G. Bimodem locks up its logfile (DSZ.LOG) during a transfer, and so no other protocol from other lines can write to that file, and may hang your system with a Network Error: File in use - Retry Abort Ignore ... To get around this simply direct the logs of the different lines to different logfiles. 3. RAM usage This a problem: EFT uses lots of RAM to store configuration information, FILES.RA and other things. Memory Allocation errors will be logged, so increase to RAM size of the task EFT is running in when running under a multitasker. I will work on that, and future version will use less RAM. 4. Fast Modems If you use a modem running with a locked baud-rate (US Robotics, Telebit, AX9224c, Telekom MDG 19K2-31 etc.), you need to edit the command-lines in the configuration file. Two things: 1. Replace all `$2' with the locked baud-rate, i.e. '19200' for most modems. 2. Somehow tell the transfer program that it has to use hardware handshake (CTS/RTS/etc.). For DSZ this is done by including a "handshake both" statement in the DSZ commandline. For the other transfer programs you're on your own... Those transfer programs that uses the FOSSIL for modem I/O EFT enhanced file transfer 07-03-91 11:23am Page 46 (i.e. CLink etc.), shouldn't need editing as the FOSSIL will take care of the handshaking and locked baud-rate. EFT itself knows -nothing- about the modem type. It just gets the baud-rate from the BBS, and uses it to calculate transfer times, and to pass it along to the external transfer programs. 5. Hidden files Beware of, that unlike like RA, EFT requires that the file to be downloaded is listed in FILES/PFILES.BBS for the user to download it. Same goes for private files (those listed in PFILES.BBS or PFILES.<no of area> when using global list path)). User must have enough private files access and private access flags for that specifiy area to download private files from it. In no case EFT will sent one of the following files: FILES.BBS, PFILES.BBS, RA.KEY, EFT.KEY. 6. Swapping EFT supports three different methods to swap itsself out of memory to give additional room to the protocol driver being run, or if you shell to dos via the ALT-J hotkey. The first and most common method is file swapping: EFT will allocate a swapfile with the name and path you specify behind the SwapDir statement in EFT.CFG. If you do not give a special SwapDir parameter EFT will default to EFT.SWP in the actual directory (that will be the temporary up/download under the actual used filearea. This file will be deleted when swapping is complete. The file swapping method will be avail on mostly all systems, except those that do not have 250k available on their HDU. The second method is called EMS swapping, and of course EFT will use EMS memory, if enough of it is available. The EMS memory must conform to EMS4.0/LIM. EMS simulators which reserve a 64k frame in lower memory are supported by EFT. As an additional bonus EFT will copy its overlays to EMS memory to always work full speed on your system. Third there is the XMS swapping method: As a unique feature EFT introduces the ability to swap itsself to XMS memory that is found on every 286 machine and above. So if you do not use a NEAT 286 or 386 machine for your BBS this is the method you will like. EFT accesses XMS memory in protected mode which is lightning fast even though EFT has to switch back and forth to and from protected mode. The only thing you'll have to do to make your 286 machine (or above) XMS compatible is to install the DOS device driver HIMEM.SYS in your systems CONFIG.SYS. HIMEM.SYS will also create a HMA (High Memory Area) your you to use. EFT will not use the HMA, since the HMA is mostly used to swap DOS itself out of the lower memory. EFT will work perfectly with a highloaded DOS and highloaded device drivers. But wait - there is one thing you'll have to give attention to: Some EFT enhanced file transfer 07-03-91 11:23am Page 47 BIOS on some older systems need special parameters to let HIMEM.SYS access your extended memory in protected mode. This parameter is to enable the A20 adress line, and if your BIOS refuses to activate the A20 line automatically when HIMEM.SYS initializes you'll have to force it to do so. If you do not enable the A20 line EFT will still find XMS memory: The High Memory Area. But the HMS is max 64k long, and that too less to swap EFT out. Until you enable the A20 line EFT will keep on complaining on too less XMS memory and will try to use one of the other methods described earlier. So check with a system utility like MFT or CHECKIT if your systems runs with A20 active after HIMEM.SYS installation. If that isn't the case here are the known parameters for HIMEM.SYS to force A20 support : device=HIMEM.SYS /machine:??? where ??? is replaced with one of these: AT for IBM AT WYSE for Wyse TOSHIBA for Toshiba Acer1100 for Acer1100 Hpvectra for HP "Classic" Vectra (AT&T) Ps2 for PS/2 Att6300plus for AT&T 6300 Plus PT1cascade for Phoenix Cascade 7. Private files Private files are listed in PFILES.BBS in each area. The SysOp may specify a security and flag setting, that the user must have to access those files. Special processing is done concerning this files on up and downloading: On Uploading, EFT checks if the user is allowed to make a file a private upload. If so, it enables the option 'enter / to make upload private'. If there is a slash as the first character in the filedescription EFT will add the file to the actual filearea, and its description to PFILES.BBS (will be created if not already there). There is one exception to the rule: If you specified a private upload directory in EFT.CFG using the 'PrivateDir' statement. In this case EFT moves the file and its description to the private upload dir. TIP: Make sure, that your private upload directoy is also in FILES.RA, so that the anti duper will check this directoy, too. Maybe you set it to a sysop level and do not let users access it, so you can check your private uploads first before you let someone take the stuff. The anti duper also checks for private files, but shows them to the user only if he has private access to the area the anti duper is currently working on, so in every situation private files and their information are safe, and no user would even recognize that there is something like private files that he can not EFT enhanced file transfer 07-03-91 11:23am Page 48 access. On Downloading EFT checks first if the user is allowed to take private files. This will work with AutoSearch, too. FileCount will also update PFILES.BBS if the downloaded file was a private one. 8. Limit Checkers There are several limit checkers build into EFT: First there is the daily download limit, that is passed via EXITINFO.BBS. The user will in no case be allowed to take more kilobytes than this value. RA calculates the daily download limit everytime it gets a new EXITINFO.BBS from a door program, so don't wonder if you see different values concerning the daily download limit on the status line in one session. Seconds there is the time limit: Users are only allowed to take files if the calculated transfer time won't exceed the remaining time passed via EXITINFO.BBS or the -t commandline parameter. The user may gain additional time if you use the UploadCredit statement in EFT.CFG accordingly. Third there are the ratio limits on kilobytes and time: The user will only be allowed to take that much files so that the limit on files won't get exceeded, even it those files would easily fit into the daily download limit. The same goes for the ratio on kbytes. Those conditions are combined with AND, so if one fails the user will not be able to download that file. To not upset the user EFT will calculate which files of the requested ones will fit into all of the limits and ratios, and EFT will ask the user if he wants to take those files instead of the complete bunch of files he requested. Of course never it is allowed to take more files than the selected protocol driver is able of transferring in one sweep. 3. Trouble-Shooting and Questions Q: Sometimes EFT says "0 file(s) transferred" after a download, even though the file(s) were sent. A: Try to increase the efficiency for the protocol used by 5 or 10 percent. For more information, please read about "Other" protocols in the "Protocol" section. Did you forgot to enable the driver to log information? Did you set the logfile to an invalid directory? Did you set the environment variables on DSZ and CDS drivers? Q: I wonder if EFT is smart enough to check such things as the callers download-limit, and if he has enough time left for downloading the selected files etc. A: Are you insulting me?! Of course EFT checks those things... However, when a user is going to upload something, EFT does not know how long it will take, and so just makes sure that he has at least 5 minutes left (for EFT enhanced file transfer 07-03-91 11:23am Page 49 typing filenames, descriptions, goofing up, etc.). Q: When a caller uses the "<G>oodbye after transfer" option, EFT doesn't hang up when done, it just returns to RA. A: To hang up on the user, EFT lowers DTR, and then expects the modem to drop carrier. Make -sure- that your modem is setup to hangup when DTR is lowered (either via a dip-switch or by the modem command '&D2'). Q: EFT gave me a "Commandline overflow" error today. Why did this happen and how do I circumvent it? A: It happens when EFT discovers that the length of the commandline it is about to execute, has exceeded 132 characters. This is a limitation in MS-Dos and usually happens when the caller selects a bunch of files to download in one session. To avoid it, lower the number of files for this protocol (check the section "Protocol keyword" for more info). Q: Sometimes I find FILES/PFILES.BBS and corrupted files in my root directory. How can this happen, and what should I do? A: You forgot to set the breakdir statement to a correct directory. Read EFT.CFG Q: EFT doesn't start the protocol driver. What is wrong? A: Well probably everything ... but maybe you set the SwapFile statement to a invalid directory? Read EFT.CFG Q: I cannot get EFT to work on my system. I simply replaced FILEDOOR.EXE with EFT.EXE on the commandlines of my menus. A: You'll have to give the -p parameter if you use a different port that COM1: This is an incompatibility with FileDoor. Please read at least the commented .CFG file. Q: EFT does not show my fancy FileDoor menus. A: Names changed! Read Support file section! Q: I try to run my protocol driver and/or the archiver for testing uploads with a batchfile, but EFT doesn't start it correctly. A: Did you forget to set the COMSPEC environment variable correctly? Q: I want to run a batchfile when arctesting the uploaded files, but EFT always says that the file was good, even if EFT enhanced file transfer 07-03-91 11:23am Page 50 it wasn't and gives credit for bullshit?! A: If you run batchfiles on the arctest commandline you'll have to use the *C macro! Only if EFT finds that on the commandline it will switch to the goodfile handshaking, and for batchfiles always eating up any errorlevel in every situation a zero value is returned. You must program your batchfile that it will create a file named 'GOOD.' in the actual directory (that would be the temporary upload directory that EFT had created for you). Only if EFT finds this it will assume that the file was correct, and will not give credit if the file is missing. Please read the section on arctesting again. Q: I do have EMS in my system, but EFT always swaps to disk? A: Maybe there is too less EMS remaining? EFT will use up to 250k of EMS to swap everything it can grab out of memory to give mayimum RAM to the protocol driver. If EFT could not allocate enough EMS it will swap to disk instead. Q: Yeck! I have EFT.LOG everywhere in my system! A: You forgot to specify a path to the LogFile statement in EFT.CFG. So if EFT want's to log something it will use the actual directory (whatever that may be in that second) creating EFT.LOG if it wasn't there already. Q: On Zmodem transfers EFT complains in the logfile that it cannot find DSZ.LOG. A: Set the DSZLOG variable in your environment, or check if it points to an invalid path and/or filename. I would skip the path on the DSZ logfile. The same goes for CDS protocols. Q: EFT tells me, that I have too less XMS memory though I installed the HIMEM.SYS driver correctly and a HMS is available. A: Maybe your BIOS needs a special parameter to HIMEM.SYS to enable the A20 line to let EFT get more than the 64k HMA in protected extended memory. See section on swapping. Q: My Bimodem does not take all of the parameters that EFT passes. A: Buy a newer version of Bimodem. V 1.24 is minimum. Q: Bimodem does not sent a file, except from the actual directory. A: Two things to remember: First you better put a -a EFT enhanced file transfer 07-03-91 11:23am Page 51 parameter on EFT's commandline! Because you omitted -a and a path statement EFT added the actual directory path to your fileareas. This may be dangerous. Second, you are maybe not using private files, but EFT does! If you have set the private security level to say 65000 and a user has only 50 as his sec level, EFT won't grant access to any filearea, because it may be possible for the user to add private files while bimodem is running. This is a security violation! In this scenario files may only be sent from the actual directory EFT was started from, because this is always added with security zero, private security zero and no access flags. Read complete documentation of RA, SBBS and EFT again! 4. Maxima o maximum freefiles statements: 16 o maximum download hour windows: 6 o maximum archiveextensions: 16 o maximum upload protocols: 32 o maximum download protocols: 32 o maximum files that can be transferred in one sweep: 64 o maximum unwanted statements: 16 o maximum password retries before return to BBS: 3 o maximum fileareas: 200 o maximum lines on BBS: 999